Click or drag to resize

Introduction

This document is intended for all audiences. However, there are technical sections that may not pertain to non-developers. IT professionals that are familiar with Windows Server should be responsible for the installation and maintenance of the Applied Epic SDK. The main users of the Epic SDK will be developers who are creating integration programs.

Introduction to the Applied Epic SDK

A Software Development Kit (SDK) is a set of development tools provided by a vendor that allows the consumer to create a customized application that interacts with one of the vendor’s software products. It may be in the form of an application programming interface (API), which is typically a compiled development library that allows a gateway into another software product’s data.

Similar to a typical SDK, the Applied Epic SDK is a set of libraries that allows developers to access the Applied Epic database from their own code—giving developers the ability to read and write data to and from the Epic database. Data from the Applied Epic database could then be used to populate other software product databases, and other software product data could be written to the Applied Epic database, as long as it conforms to Applied Epic’s business rules. Applied Epic’s business rules are enforced by the methods provided in the Applied Epic SDK.

The Applied Epic SDK is modeled after the screens that display in Applied Epic. Going through the areas and workflows in Applied Epic can help you decide what area of the Applied Epic SDK you want to use. If the area is currently supported by the Applied Epic SDK, all fields available on the screen are available via the Applied Epic SDK. Areas currently supported by the Applied Epic SDK are listed in the Areas Of Integration section.

Here is how the Applied Epic SDK works. The developer creates an application that uses the Applied Epic SDK service. The Applied Epic SDK service then uses the Applied Epic business rules to retrieve or write data from your Applied Epic database. Data being retrieved or written passes through the Applied Epic business layer through the Applied Epic SDK service. This means that there is seamless integration with Applied Epic, and using Epic SDK doesn’t have an impact on Applied Epic performance.

After going through the business layer, the Applied Epic SDK service then returns the resulting data back to the calling application. This data can then be used for any of your integration needs, such as writing the data to a website, accounting system, or reporting system. Depending on its design, you may be able to use the external system to modify the Applied Epic data and then return it to production database. The following is an illustration of how this whole process works:

EpicSDK

As you can see, use of the Applied Epic SDK can eliminate double entry of data, ensuring that your data is consistent among all of your applications. This will simplify your work flows and produce a tighter integration of Applied Epic with your other applications.  Although the Applied Epic SDK can be used for batch processing, it is not recommended. For the best performance, the SDK should be used for real-time integration. If your needs include batch processing, contact your sales representative and ask them about the Epic Bulk Extract utility.

The Epic SDK can also be run in a DMZ environment. Such an environment would use a dual firewall setup to secure the Epic SDK Server. On the internal firewall, port 8222 must be opened to provide SDK server access to the internal Epic Central Server. On the external firewall, port 433 must be opened for the Epic SDK Server. The following is an illustration of the Applied Epic SDK Server running in a DMZ.

EpicSDKDNZ

If you do not have a developer or consultant available to create the applications needed to use the Applied Epic SDK, Applied Systems can build custom integration applications to fit your company’s unique needs. If you would like to learn more about this service, contact your sales representative.